Web Services: Datenbank-Design

Im zweiten Teil dieser Artikelreihe wurden in ASP.NET die Rahmenkomponenten und -anwendungen für die beiden Anwendungen von John und Tom erstellt. Eine Logging-Prozedur und die Ausnahmebehandlung wurden für jede einzelne Komponente festgelegt. Nun kann man darangehen, die Datenbank zu entwerfen und gespeicherte Prozeduren sowie den Zugriffscode für die Datenbank zu schreiben, alles in Übereinstimmung mit den vorher festgelegten Anforderungen.

1. Web Services: Entwicklung eines Szenarios
2. Web Services B2B-Implementierung: Komponenten, Ausnahme-Behandlung und Logging

Datenbank-Design

Man kann eine Implementierung sehr gut mit der Modellierung der Datenbank beginnen, also mit einem Bottom-up-Ansatz. Andere Entwickler bevorzugen einen Top-down-Ansatz und erstellen zuerst die Benutzeroberfläche, um sich dann bis auf die Datenbankebenen vorzuarbeiten. Dieser Ansatz birgt allerdings die Gefahr, dass man einen Code erhält, der zu eng auf einen speziellen Zweck zugeschnitten ist und daher häufig nicht wiederverwendet werden kann. Wenn man einmal von den konkreten Anforderungen abstrahiert und zuerst Diagramme erstellt, welche die Beziehungen der einzelnen Dateneinheiten untereinander wiedergeben, ist die Chance größer, eine flexiblere und wiederverwendbare Datenschicht-Komponente zu entwickeln.

Die Hauptkomponenten beim Datenbank-Design sind die einzelnen Dateneinheiten, Beziehungen und die Normalisierung. Wenn man den folgenden Schritten bei der Erstellung einer Datenbank folgt, dürfte man jeweils zu einem recht exakten Design gelangen:

1. Dateneinheiten bestimmen: Dies beinhaltet eine Analyse der Kunden-Anforderungen. So findet man heraus, welche Daten gespeichert werden müssen und wer der Besitzer dieser Daten ist. Normalerweise ergeben sich die Dateneinheiten aus den Substantiven der Sätze der ausformulierten Anforderungen.
2. Festlegen der Datenstruktur: Für jede Dateneinheit muss man entscheiden, was genau gespeichert werden muss, um diese Dateneinheit zu beschreiben. Diese Daten werden zu Feldern in den Datenbanktabellen. Die Kunden haben oft keine klare Vorstellung davon, wie lang Textfelder sein sollten oder wie viele Stellen einzugebende Zahlen haben, man sollte sich also am besten auf seinen gesunden Menschenverstand verlassen, wenn man die entsprechenden Felder anlegt.
3. Systemfelder ergänzen: Fast jede Tabelle erfordert Felder, die sich nicht direkt aus den Anforderungen ergeben. Zu den Systemfeldern gehören z. B. Zeitstempel mit dem Erstellungsdatum, Primärschlüssel, Datum der letzten Aktualisierung etc.
4. Verknüpfungen erstellen: Hier analysiert man die Dateneinheiten und erstellt Verknüpfungen zwischen diesen. So muss z. B. ein Auftrag mit einem bestimmten Kunden verknüpft sein. Deshalb muss die Dateneinheit „Auftrag“ einen Fremdschlüssel für die Kundentabelle enthalten. Die beiden häufigsten Arten von Verknüpfungen sind die 1:n- und die n:n-Beziehung. n:n-Verknüpfungen erfordern eine separate Hilfstabelle, die nur zwei Felder mit Primärschlüsseln enthält.
5. Normalisierung der Dateneinheiten: Hier führt man eine abschließende Analyse des Datenbankmodells durch und optimiert es, indem man redundante Daten in eigene Tabellen auslagert. Man kann die Normalisierung allerdings auch so weit treiben, dass die Performance darunter leidet, weil es zu viele Tabellenverknüpfungen gibt. Man sollte also aufpassen, wie weit man mit der Normalisierung gehen will.